產銷規劃 (S&OP) part 3

過去有些人把配銷網絡上的規劃稱為DRP (distribution requirement planning)，但我認為DRP也應該是S&OP的一部分，因為在配銷網絡上的庫存會是更重要的供給來源之一。因為這些可能都是成品(或是接近成品的kits)，所以它們必須要趕快送到終端客戶、消費者的手上，不然當消費者的需求一改變，這些就變成了沒人要的呆滯庫存了。

要管好配銷網絡，其重點是如何管好、取得網絡上的資訊。如7-11的策略是透過多次配送來降低配銷規劃的影響，因為配銷規劃的不準確所造成的短暫缺貨可以在下一次配送(幾個小時之後)補足。但是如果是幅員廣闊、配送不易的地區，這樣的策略就不一定行得通；再者油價的節節高昇也會讓他們開始思考配送的效率。因此配銷規劃的準確、即時性的需要就會逐漸提高，而無法掌握配銷網絡的資訊就沒有辦法改善配銷規劃。

一般的製造工廠、企業營運是透過製造執行系統(MES, manufacturing execution system)以及ERP (enterprise resource planning)等資訊系統來收集作業資料；許多公司非常注重在工廠端的規劃與管理，例如替代料的選用、工單排程、在製品控管、製造成本降低等議題，因此透過MES/ERP加上APS來協助管理規劃。但是在配銷網絡上，因為物品可能在移動、在儲存，裡面有倉庫的管理、運送的追蹤等等，有時候即時性的資訊並不可得或不正確，因此讓配銷規劃的難度增加。

但是配銷規劃往往是對消費者最接近的規劃，因為它關係著什麼時候消費者可以得到他想要的產品。又因為現在的消費者對產品的需求已經轉變為「new and now」，他們已經不想等待，而且其他的競爭者如果可以推出類似的產品而且更快的送到他們手上，那麼他們就可能會轉向競爭者的產品。

因此產銷規劃中，除了決定如何平衡供給與需求以達到最大的利潤外，也必須要基於配銷的考量來一起規劃，就是基於配銷網絡上，如何分配供給給所有的需求，讓每一個期間的利潤的總和能夠極大化。

產銷規劃 (S&OP) part 2

最近正在看一本書，The New Rules of Retail，裡面談到整個零售產業經歷Wave 1、Wave 2而目前正進入Wave 3；而Wave 3裡一個重要的趨勢就是對於整體價值鏈的「control」(控制)，因為要能控制，才能確定完全掌握對使用者體驗(user experience)的控制。

而書中所談到的控制並不等於「擁有」，而是「掌握」價值鏈上面所有的動態而能夠立即反應。對於供應鏈而言，這正是透過供應鏈的可視性進而透過產銷規劃來對需求進行反應。唯有能夠有整體供應鏈的可視性加上靈活的產銷協調機制才能確定對供應鏈這端的「控制」，進而達到這本書上提到消費者現在的一個期待，由過去的「new」變成「new and now」，也就是「立即擁有新的東西」。

因為消費者行為、期望的改變，而零售業必須因應來改變業務模式，相對的後端的運籌(供應鏈)也要相對的靈活調整。而對於整體供應鏈上所有大大小小行動、變化的掌握是越來越需要，因為資訊的落後就會造成決策的錯誤，進而造成企業的損失。

所謂的產銷協調、規劃(S&OP)的成功，並非只是單純的定時進行銷售(銷)與供給(產)的平衡這麼簡單，而是背後如何取得正確的資訊而在這樣的平台上進行調度。而很多時候談產銷規劃時，如何取得資訊的重要性都被忽視，而是一味的著重於規劃的機制、規劃的邏輯。

如果看一個自有品牌的公司運作，他面對的是銷售渠道(channel)或是配銷網絡(distribution network)，如果他沒辦法知道銷售點(Point of Sales, POS)的資訊時，他看到的這些配銷網絡資訊通常是被曲解過的，例如：配銷商是批量進貨，需求是斷斷續續的，或是銷售遲緩而造成配銷商滯銷，所以終端配銷網絡上其實有很多庫存，但品牌公司還不知道應該停緩供給備料而造成繼續進料、庫存增加。而對他的上游ODM/OEM而言，他如果沒辦法掌握生產狀況，也不知道未來的供給會如何增加庫存，或是也沒辦法進行自己後續營業的預估。

在今日消費者有太多的選擇的情形下(Wave 3的特性之一)，零售、品牌公司莫不希望即時反應消費者的需求與期待，如果對於價值鏈(或供應鏈)的掌握不夠，像恐龍一樣反應遲鈍(這裡我有個疑問：為什麼恐龍就是反應遲鈍？) 沒有辦法即時根據消費者的需求進行反應，那這個公司很快的就會被淘汰。

因此我認為供應鏈管理將是一個企業極關重要的課題(當然不只是因為我是搞這個的)，而其中如何有透通的資訊來管理產、銷平衡更是一個關鍵。

產銷規劃 (S&OP) part 1

我認為供應鏈規劃裡面一個最重要的課題就是產銷規劃 (S&OP)；它是整個供應鏈執行的核心機制（請注意，是供應鏈規劃，不是供應鏈管理）。看一個公司進行產銷規劃時所參與的層級，就可以知道這個公司運作的好不好。

幾個星期聽到一段分享，他提到當初Steve Jobs剛回到到Apple時，他自己會參加產銷規劃會議，參加產銷的決策。我想現在的Tim Cook是供應鏈管理的專家，應該也不會改變。

為什麼產銷規劃如此重要？如果我們想像天平的兩端是需求與供給，而天平絕少有機會平衡的；而產銷規劃就是那股維持天平平衡的力量，可能去拿掉一些需求或是增加一些供給，最終就是要讓天平能夠平衡。如果天平傾斜了，那就會有很多的問題會發生。

但是產銷規劃做的好的公司有多少？我的經驗裡，每個公司都有很大的進步空間。為什麼？我認為有幾個因素：

第一：部門之間的個人主義

作為生產部門，主要的績效指標就是要有最大的生產效率，讓生產成本最小，最好都不要換線、做簡單良率高的產品。但是對於銷售部門而言，他的績效來自於營業額，他要價錢高的、客戶大的，而這跟生產部門的目標或許是有衝突的。

而在各部門有衝突的情形下，其實產銷規劃就應該是一個平台讓不同單位在這個平台上進行溝通、討論而得到共識。我這裡提的平台並不一定是系統平台而是一個讓所有單位一起參與討論的機制。

但是很多的產銷規劃會議都是看到規劃單位主導，與銷售部門進行協商，而財務、採購、研發、行銷等部門卻極少參加。但是他們也都跟產銷最後的決定相關，卻沒有機會表達意見、參與討論。

第二：資訊的透明與正確性

在供給不足的時候，每一個銷售人員會「搶」供給，但是如果他的「單」比較小，那他可能會被犧牲掉，搶不到貨。所以？他就會把預測放大來搶供給。因此資訊就不是正確的，進而造成決策的偏差。

就算有了資訊，這些資訊是「靜態」的，而產銷規劃很多的資訊必須是「動態」的。何謂動態？其實就是「模擬」、「what-if」。因為供應鏈是一個系統，動了一個部分就一定造成某的部份的影響。所以在進行產銷規劃時，需要很多動態的分析、模擬；在供給小於需求時，把供給分配給某個需求時，一定有其他需求受影響（數量或時間）。如果沒有看到動態資訊，怎麼可能做完善決定？

第三：對產銷規劃機制的認知

台灣可能是以OEM/ODM為主的產業型態，企業主的思維都是以「搶單」為主，先搶到手在說，所以產銷規劃就變成處理這些訂單交貨問題的機制。產銷機制對於中、長期的重要性並不是很明顯。很多的產銷協調會議中，變成是銷售單位想辦法強調其訂單的重要性，而可以變成生產排程的優先者的一個場合。本來產銷協調的機制是透過產、銷雙方對於中、長期的供需狀況進行討論，以穩定供應鏈提昇生產效率、滿足需求為主的；但是在太多的插單、急單的狀況下，造成了「計畫趕不上變化、變化不及老闆的一句話」這樣的情形。

曾經聽過Samsung的銷售人員如果是要要求急單或插單時，他是會被檢討為什麼與當初的產銷規劃有差異的。而在台灣的OEM/ODM型態下，接單為大，誰會去檢討這些接單回來的銷售人員，何況接單的可能就是大老闆啊！

對供應鏈管理的看法（五）

其實導入APS並不但單純導入系統（這是老話，但也像是空話），前面也聊過供應鏈的問題是盤根錯節的，通常看到、感到的問題都只是表徵或是冰山一角。所以藥方也應該是全面性的，才有成效。

前年在一個導入專案時，就看到整個規劃流程因為產品主檔資料、銷售部門的行為以及績效衡量權責不清等等的影響，造成供應鏈運作無效率而且造成庫存很高（他們一開始提到的表徵），且讓我慢慢道來。

電子零件生產、測試後，可能因為品質的等級而分成不同的級別；而不同的客戶可以接受的級別就不同。龜毛的客戶只接受最佳等級的，不龜毛的就什麼都可以。加上產品改版又產生不同版次的產品，客戶也不是什麼版次都接受。簡單的說，要能夠出貨，必須考慮「版別」與「品質等級」兩項因素，如果有3個版別、4個品級，那就是有12種成品的規格。

所以銷售部門就掌握了「配貨」的生殺大權。他們的運作流程是由銷售部門對生管部門提出需求，然後由生管部門進行規劃、交由製造單位進行生產，然後交給銷售部門「配貨」出貨。

對銷售部門而言，他的目標是提高訂單的及時交貨率，所以就會將他們打算出貨的數量整理好，交給生管規劃排產。

而生管的績效指標是：1)產能利用率 2)銷售需求滿足率 3)庫存量。所以生管就將銷售部門所提的需求直接進行排產。假設每生產10個成品大約可以有6個是A級品、3個B級品、1個C級品；但是銷售部門就只給一個數字：100個。對生管部門而言，他就想辦法備100個的料、做出100個成品就好。這樣他的產能利用率達到了、也滿足了銷售需求、而料也只買了100套，沒有多餘庫存。

等到銷售部門要「配貨」時，卻發現只有60個A級品，出不了100個的那張訂單。然後就是急單、趕快備料、趕工...一堆急事。更甚者，那些B級、C級品如果沒有客戶要，那就慢慢的變成呆滯庫存，最後就只能當呆帳打掉。以上還沒講到「版別」，如果加上版別，你可以猜到整個庫存的數量會變得如何的恐怖。

這樣的問題是APS就可以解決的問題？當然不是，自產品開發就開始有問題了：

問：為什麼要換版別？

答：因為BOM表裡面的零件換了

問：為什麼換零件？

答：因為供應商不同，所以同樣的零件料號不同；所以料表就不同了

問：幹嘛供應商不同就要編不同料號？

答：因為公司規定

問：.........

銷售呢？

問：為什麼要配貨？

答：因為客戶能接受的版別、品級不同

問：都只能接受最高品級、最新版別嗎？

答：不一定啊，看客戶

問：那為什麼不先去扣掉現有庫存再把淨需求給生管規劃？

答：庫存是生管單位的責任，他自己要算

問：........

可以看到這些問題都不是APS就能夠解的，而是公司政策、作業流程、衡量指標等等面向相關的，如果單純的以為APS就能全解，那麼一定是太傻、太天真了。

但是一般APS的導入不會先就業務流程面分析、建議改善，而是會直接進入系統功能需求的討論，想辦法把功能做出來。但是可能被其他面向的問題搞到根本無法上線，讓導入團隊與客戶都陷入泥沼之中。

甚至遇到比較「驕傲」的公司，他們會認為自己的流程作法是best practice，根本不需要改，而是要由系統來fit他們。而這些APS都是基於某種預設流程架構所開發出來的，不一定能夠支援這些奇奇怪怪的作業模式，因此最後還是落得失敗收場。

所以真正要做完整、正確的系統導入，還是需要先由使用者提出現有困境、問題為何？如何來衡量這方面的績效？然後透過作業分析，找出所有相關的原因進行改善，這些原因有的甚至是系統導入的前置作業以及必要條件，如果沒有完成，系統也就無法導入運行。在這樣的過程裡，進行前期的工作時必須也要了解未來如何透過系統來輔助進行；而後來的系統建置人員也要了解系統所將扮演的角色與提供的功能。

講起來簡單，但是往往因為時間的壓縮、預算的限制，都是直接進入系統建置，只想求「自動化」，而並不是透過系統「優化」作業。結果反而是專案無法上線、系統效果不佳，更是讓人失望。

站在「解決問題」這個角度看，如果真的要解問題，是沒有辦法偷懶的，省去任何一個步驟都不是做好的。

除了導入的方式以外，執行的「人」更是關鍵所在。

第一，顧問終究是顧問，他們不是真正operate business的人，對於作業面的細節並不會完全瞭解；甚至對於產業的瞭解也不會如使用者們這麼深入。我認為，顧問的價值是將使用者的需求、看法結構化，並透過整合提供一個完整的picture。因為使用者在日常生活作業上都是以功能silo為運作中心，例如前面的例子，銷售人員才不管生管規劃的困難，生管也去了解銷售人員如何配貨。而對於一個好的顧問而言，他必須要能了解整個所有的流程，每一個單位的想法、看法，才有機會設計出好的流程與系統。

第二，不要過於相信「方法論」。業務諮詢顧問公司會將一些工作方法整理為所謂的「方法論」，而認為業務諮詢可以按照這樣的方法論來按表操課。方法論就像是一個指南針，它給你一個方向，但是應該是要了解它的精神，活用它。因為每一個客戶、每一個產業、每一個部門都有其特殊性，是不可能期望一套功夫闖江湖的。通常方法論是講述做好一件事情一個一個的步驟，但是進行步驟一時能不能作一些步驟二、三的工作？到步驟三的時候，是不是會需要回去重複步驟一的工作？這都是有可能的。

第三，跳出框框。業務顧問通常就是談談流程、設計未來該怎麼做，而package顧問整天擔心的是功能能不能符合需求，而常常造成兩造的對立(如果兩部分是分開，由兩個團隊來執行，更是衝突一堆)。我看過三個案例，所謂業務流程改善與系統導入是分開，由不同團隊導入的，其結果都是不如預期的。因為業務顧問就是只看他們所談論的流程，並不去考慮系統如何支援、落實。而系統顧問只看功能能不能做到業務需求，而沒有去challenge流程的合理性。當然，在這三個案例裡，因為業務流程已經被設定，系統商只能概括承受沒有機會去挑戰其合理性。不過我想談的是，這就是業務、系統分開的弊端；如果使用者沒有瞭解兩個之間的關係，而還是分開進行，這樣的問題還會一直下去。

第四集的外傳

Edison大哥對第四集有些comment，剛剛對這點有個想法，把它寫下來吧。

我認為如果一個顧問公司真的要把APS導入做好，應該是我個人認為的「total implementation」方法。所謂total implementation應該要結合issue-based consulting以及package implementation兩大塊。

當客戶找上顧問公司時，他們其實是在找一個「solution」來解決他們遇到的問題。前面也聊過，供應鏈的問題通常都是盤根錯節，並非單一事件造成(system thinking)，所以首先應該要對於他們所遇到的問題，抽絲剝繭來找出所有相關的原因。如果是業務流程的問題，就需要客戶相關業務部門的人出來想辦法解決，而透過系統輔助執行改善後的流程。

一般的迷思是，因為系統導入的時程短，所以專案開始之後就開時急急忙忙的談to-be，而沒有做前面issue-based分析、改善的動作，而直接就使用者天馬行空的想像來設計to-be流程。結果到了驗證的階段，才發現不可行；因為流程上的衝突、問題沒有解決，而to-be的流程根本不符現實。

顧問公司所提供的價值應該是為客戶「解決問題」，而不是單純的「上系統」。但是有趣的是，系統廠商（或顧問）只關心功能符不符合、會不會需要客製很多；而業務顧問很多只看「策略」以及很高的「流程」，沒有看到作業面的實施。而且系統與業務顧問們，自古文人相輕，互相看不起；鮮少看到成功合作的案例。

但是回來看客戶的需求，他們是需要外力來幫忙解決問題的，而單只有系統或業務，根本沒辦法幫他們解決問題。所以買了業務顧問的服務，他們覺得只拿到一本厚厚的報告；買了系統卻又沒辦法實用，搞到三方面都灰頭土臉。

我心裡理想的「total implementation」作法，是由一群有系統概念、知識的業務顧問與具備業務分析手法、了解業務內涵的顧問們一起，與客戶一起由問題的了解、分析，找到真正的原因與解法，然後看看如何透過系統來輔助執行，並透過量化的衡量來檢視成果。或許這不是新的想法，很多公司也「號稱」是這樣做，但成敗還是在「人」，因為有系統概念與知識的業務顧問不多，而很多系統顧問也不去了解業務內涵，所以都還是一人一個調，各唱各的調。

所以一句話，「知易行難」。

對供應鏈管理的看法 （四）

首先，感謝各位朋友的關心，但是我比較期望的是透過提出我的看法，能夠跟各位交流，不要只按個「讚」啦！

第二，有時候在高鐵上還是想看小說就好，不會每天寫這些東西啦！

廢話少說，這次來聊聊我對建置APS的看法，但是我覺得以下這一段非常危險，可能要列為限制級。乾脆加上「本文為虛構，如有雷同，純屬巧合」比較好，哈哈。

其實客戶決定用APS時，我看過兩種情境：

情境一：依稀之間，覺得好像有那麼一些些需要，但是不清楚APS能做什麼，然後在APS vendor的遊說下（比較時髦的用語叫做：忽悠），決定用APS。有時候，甚至是因為資訊部門需要績效，所以硬叫規劃單位來搞個專案。

情境二：業務單位非常確定需求是什麼，但是對APS能做到怎麼樣還不清楚，然後在好多輪的簡報、demo、POC...等等之下，選了忽悠最好的廠商。

情境二是比較少見，不過不管是一或二，兩種情境都有一個共通點：對APS功能不熟悉。所以雙方就在不怎麼互相了解的情況下要開始專案了。然後就可以看到使用者非常有創新能力的開始想像未來該如何如何來用這套系統（開始構思原子小金剛的設計）。如果加上前面有個「顧問」公司幫客戶進行「業務流程改善」(BPR, business process re-engineering)，可以看到整個創新能力真是令人刮目相看，由原子小金剛變成無敵鐵金剛的設計了。

然後APS建置團隊就在水深火熱之中，與function gap來奮鬥，嘗試建造這尊無敵鐵金剛。姑且不談是不是建出無敵鐵金剛，通常使用者後來就發現，他要的只是一台腳踏車，讓他由走路變成騎腳踏車（而且還要一些時間才學的會騎車）。因此這座打造出來的「無敵鐵金剛」就被束之高閣、打入冷宮。

所以我覺得一個成功的APS導入，使用者要好好想清楚真正的需求到底是什麼？然後怎麼透過系統來幫助達到這樣的需求。而且滿足需求都是會付出一些代價的，例如：提供一些資料、規範一些作業程序、定義一些作業規則；而且這些東西都需要一直更新的，不是一次做好就結束了。整個走一次，才能確認需求在哪裡。

需求訂出來，並不就這麼結束了；接下來應該還要定義出如何衡量成績的具體指標，並進行business case的分析。例如：常常說導了這種系統會提高OTD (on-time delivery)，那應該看看目前是多少，然後目標會是多少，其中的效益會是怎樣？如此一來才能讓專案與實際績效連接在一起。不過另一個事實是，改善並不是單一原因造成的，例如：OTD提昇，是真的系統的效益？還是營運長最近盯的比較兇？不過，透過一些績效衡量的分析，讓使用者詳細檢視他所提出來的需求、想達到的業務目標，是一個好的作法。

(待續)

對供應鏈管理的看法 （三）

對於APS因為有太多的教訓，或許會是最多想法的吧。

第四，APS其實是透過好幾個模組來cover不同的業務模組。主要可以分成：需求管理(demand management)、供給規劃 (supply planning)、訂單回覆(demand fulfillment)三大塊，而這三大塊裡面又有不同模組來提供不同的功能。

例如，需求管理是只將與客戶、銷售管道(channel)...等等不同來源的需求資訊透過資訊分享的方式收集到一個地方，讓需求的資訊可以讓所有相關人員看得到。這裡面談到與客戶、銷售管道的協同作業與資訊收集，這部份可以透過簡單的excel、文字檔傳遞一直到複雜的協作資訊系統整合來達到。然後再透過某個平台將需求資訊整合、顯示出來；這部份大都是將需求資訊以不同角度、不同維度呈現給相關人員。

而供給規劃就是透過一些演算法，考慮供給的限制計算出供給計畫來滿足需求。因為規劃區間的不同，供給規劃又有分成主生產排程(master production schedule, MPS)、細部的工單、採購單的計畫以及生產排程等等，這部份就請參照一些講MRP II的資料。

可以看到整個規劃的流程被切分成很多的步驟，而在這些步驟中進行資訊(資料)的傳遞，一棒接一棒完成一次次的循環。

首先，當一個公司發現它有供應鏈規劃的問題時，使用者知道該拿哪個模組來解決？對於需求管理與訂單回覆或許比較直觀，但是對於供給規劃上卻因為規劃區間不同，這些模組的功能、設計是有所區分的，並不是能夠一體適用的。

有些客戶他們的想法是「買一個系統，解決所有的事情」，所以買了主生產排程的工具，期望它能進行生產排程；或是買了物料需求規劃的模組，又希望它能夠協助進行各廠之間的產能分配合理化。而導入的團隊如果對於系統定位、客戶需求沒有辦法完全了解、清楚，就會造成雙方的痛苦。導入的一方會因為滿足客戶需求而整天與系統的gap奮鬥；客戶覺得為什麼簡單的業務需求沒有辦法做到。

其次，規劃是個動態系統 (dynamic system)，當需求資訊傳遞到供給規劃模組時，需求可能又已經變動了。這就是彼得聖吉在「第五項修煉」裡面所說的，一般的人缺乏「系統思考」(system thinking)。因為我們所受的教育訓練，一個大問題是可以被拆成數個可以處理、解決的小問題，然後一個一個解決這些小問題後大問題也就跟著被解決了。但是在一個動態系統裡，問題是有交互作用的，當採取一個行動時，會有回饋(feedback)，所以問題不是可拆解的。

有點離題，拉回來一下。例如：當我們進行供給規劃時，通常會看需求的時間、數量、客戶等等來決定優先等級，所以當有供應限制時，就可以將供給分配給優先級較高的需求。當銷售人員知道這樣的行為後，如果要「搶量」的時候，他們就會把需求預測放大、時間放早一些...等等來搶供給。

另外在供應「鏈」上的成員也會根據自己的判斷來決定相對的行動，而這些決定可能造成整體供應鏈上的波動，進而影響整體供應鏈的運作效率。有一個有名的實驗，叫做「啤酒遊戲」就可以演示這樣的行為。

所以這些APS將問題拆解後，系統之間需要更多的整合、資料傳遞，將規劃的時間拉長，進而就會遇到更大「動態系統」的問題。除非有一天系統能夠快到很快的完成end-to-end的規劃循環，使用者可以更快的進行整體規劃，用很短的時間由需求預測變動進行供給規劃，而透過規劃出來的供給計畫來答覆訂單。簡言之，以極短的時間減少系統變動造成的影響。

第五，系統只是輔助。(老梗是：左手只是輔助，出處詳見灌籃高手)

APS導入的成功，80%以上是靠使用者的流程、作業方式來決定。例如前面講到需求規劃，它是一個平台協助收集需求資訊，將需求的資訊在不同面向的不同維度中顯示出來，讓使用者方便檢視、管理。它收集來自銷售通路、客戶、銷售人員判斷...等不同來源的資訊，而呈現在一個平台上。講起來非常簡單，事實上很多人也都認為需求管理是最簡單的模組；但是魔鬼就在細節裡。

請問，銷售通路上有大盤、中盤、零售...等，誰要給你資訊？大盤的資訊怎麼來？中盤怎麼來？為什麼通路要給你資訊？對客戶而言，提供預測有什麼好處？即時供貨？如果是大咖的客戶，它不給你預測，單下來了，你接不接？小咖的乖乖的給預測，但是供給不足的時候，它都是第一個被犧牲的。(需求優先級，還記得嗎？) 公司內部的銷售人員呢？他給你預測，那是代表他的quota？光光這些問題就是作業上先要釐清處的，而這些問題釐清後，才能來談怎麼將資料呈現在平台上。

如果看訂單答覆，那更是複雜。誰說訂單一定根據ATP來達交？尤其在台灣以ODM/OEM為主的公司型態，訂單都是先接了再說。只怕沒單，不怕沒辦法交，不是嗎？

所以在導入APS時，有太多的業務流程、行為要先釐清，規則要講清楚(但是規則是講不清楚的)，才能將這些東西設計在系統裡面。所以系統的工，真的只有不到20%的effort。

但是這些賣軟體license的人，他一定跟你說：我內建best practice，你只要一樣畫葫蘆就好。因為他要你趕快買license，至於怎麼用、怎麼上線，那還有很多時間可以來好好討論，或是交給資訊服務商來處理。 (開始變成自白書了....XD)

有時候則是這些vendor對於系統也不是很清楚或是也不了解業務流程的重要性，所以他在賣的時候也不知道改變客戶現況讓系統有機會來支持客戶作業的effort是很大的，甚至是成功建置決定性的因素。這樣的錯誤認知下，APS的成功建置就不太可能了。

第六，使用者錯誤的期望

Steve Jobs說，”you can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.”使用者剛開始接觸APS時，一定對它有個美麗而錯誤的期待：「一鍵到底、快樂無比」。他們會提出很多想像的需求，然後把建置系統的人搞到快瘋掉；但是開始驗證的時候，你卻發現他們其實不要用那些功能或者沒辦法用那些功能。

APS就是拿資料進去，根據你給的規則進行計算、呈現。所以你要給它 1.資料 2.規則。但是使用者有時候就是沒辦法「維護資料」，然後他就跟你說系統出來的結果「不對」、「不好」、「不正確」。然後使用者就會開始要你放「default」值或是給你另外的一套規則來產生一些必要的資料，然後又是一個輪迴。

另外使用者也可能會將一些很天馬行空的想法，希望作在系統裡。有時候，我甚至懷疑那是現在電腦科技可以實現的嗎？如果有個原子小金剛來訓練一陣子，那可能性還高些。

其實我也看到很多使用者有個很奇怪的心態：希望系統全自動，但是又怕自己的價值不見了。簡單講，有了原子小金剛，那還要你幹嘛？

講了這麼多，那該怎麼做呢？下次在繼續來聊這段。

(待續)

對供應鏈管理的看法（二）

2001年由user site轉到vendor site之後，遇到很多很好的同事，very smart、very intelligent，其中一位韓國同事給我很多啟發。當我負責的模組已經完成之後，我大概就是在客戶那裏度日子而已，並沒有什麼特別需要做的事情。而他就跟我說，如果我有空，為什麼不把我對這個產業、對這個專案所學到的、看到的、想到的記錄下來？這一次，我也只是想把我過去幾年對供應鏈管理這個領域所想的、看的、學的記錄下來，只是野人獻曝而已。

既然大部分的人講到供應鏈管理都是想到先進規劃系統(advanced planning system, APS)，那我就先來講講這一塊吧。

一開始，我發現很多客戶都認為有供應鏈上的問題，就導入APS就可以迎刃而解。我記得有一本書將這種期待稱為：silver bullet of SCM。（我猜就是用銀子彈就可以搞定狼人這個問題來比喻）我覺得會有這樣的期待不能說是使用者的無知，而是這些解決方案的軟體商也一直這樣對使用者洗腦。反正，只要導入系統，就可以跟Dell一樣無堅不摧...等等的。所以在1990後段到2000前段，一堆客戶導入這些APS。

但是結果呢？我想由台灣這幾年APS vendor的狀況就可以看得出來。我想很多使用者對於「效益」應該是很失望的。為什麼？

首先，我們看一件事情：如果要把某個作業或流程變成一套電腦系統，它必須要有很清楚的規則，而且確實依照這樣的規則來執行。所以在現場執行所用的交易系統(manufacturing execution system, MES)就可以將製造現場的規則建立在系統中，讓作業員按表操課。公司的商務交易，結算財務成本資訊的交易系統，ERP (enterprise resource planning)，也是可以將業務交易的規則建立在系統上，讓公司由銷售、採購、生產等等都能依循這些規則來作業。

但是規劃系統呢？我常常比喻，那就像你開車用的GPS，當你完全不知道的時候，你會依賴它，但是如果你稍稍知道一些捷徑時，它的建議你可以完全不理會。為什麼？因為它不是交易系統(transactional system)，你必須遵循的；它是決策支援系統(decision support system)，僅供參考。加上你的規則是必須心領神會，講不清楚、說不明白的，你怎麼能期待可以在電腦系統裡呈現？？

我記得在第一個專案時，我跟客戶討論S&OP (sales & operation planning)的流程，他講到最後，就用一句話來說：「所有的考量，我沒有辦法講清楚，因為這是一個art」。請問art怎麼呈現在系統裡啊？

第二，這些系統的設計是有一套預設邏輯的，在day 1，顧問都會希望你照著弄。不相信嗎？你聽過「最佳實踐」吧？也就是所謂的”best practice”啦！這就是系統預設的運作方式，它希望你照著用。

但是何謂最佳實踐？台積電的best practice是聯電的？三星的best practice是友達的？問題沒有那麼簡單吧！每個公司有其特色、產品也不一樣，老闆也不同，怎麼可能能直接套用？？所以每一個公司的使用者會有兩個很矛盾的講法：「我是很特殊滴，別人的作法我們不能用」，講法二：「請你們跟我們多講講別人是怎麼做的，讓我們能夠學習」所以我個人的結論是：沒有best practice這回事，每一家公司都應該根據公司產品、組織、人員、實體供應鏈的結構來找出最符合公司運作管理的方法。

在這樣的情形下，對於系統而言就很困難了，因為它必須要有「彈性」來符合每一個公司的運作方式。偏偏對於APS而言，修改核心的邏輯幾近不可能。如果看台灣大部分OEM/ODM的公司，他們所面對的客戶很多，每一家都有不同的要求，那APS如何能夠來同時處理每一家公司的需求？

第三，在1990年末段，透過這些APS廠商的努力，把數學帶入實作，透過數學模型來解決生產規劃的問題。但相對的，這裡面的模型並不容易理解，連軟體商的人員都未必能夠完全控制數學模型解出來的答案（因為變數太多、限制太多），對於使用者而言如果要隨著業務需求來調整模型（系統設定），那是非常困難的。

（待續）

對供應鏈管理的看法（一）

很多顧問公司都覺得供應鏈管理這個practice的生意不多，但是又好像不能沒有，因為很多的議題又都是供應鏈相關的。結果就好像雞肋一樣，食之無味、棄之可惜。在這個領域搞了幾年，把一些心得記錄下來，各位先進也可以指導一下。

首先，先由什麼是供應鏈管理(Supply Chain Management, SCM)來談起。

有些公司，尤其是軟體公司、系統整合公司，直覺的想到一些供應鏈規劃軟體，也就是先進規劃系統(advanced planning system, APS)。如i2、APO等等。但是這是完全把SCM給講小了。記得還在業界時，資訊長就對著我們幾個導入APS的專案成員說：「請你們不要說你們在搞supply chain，你們不是！你們只是導APS。」一語中的！

那麼什麼是SCM? 很多書上都有解釋，你也可以看看Wiki或是google一下。我最近的領悟是：supply chain。也就是「供應」的整個「鏈」結。

例如：我買了一支iPhone，整個供應鏈是由Corning的gorilla glass、A5 chip由矽晶圓的生產封裝測試、電池的生產...等等，富士康組裝，中華電信的配銷，一整個所組成，然後才能把iphone交到我的手上。這整個「供應」的「鏈」結上所有的活動，都是供應鏈管理的範疇。

這裡面有：研發、採購、規劃、生產、銷售、配送...等等很多很多的活動，而這些都是供應鏈。所以，如果真要講供應鏈管理，幾乎所有的practice 都在這個領域之內。

但是，為什麼覺得生意不多呢？我認為有兩大原因：

1) 客戶的痛點在作業面

因為一般客戶在供應鏈上的問題都是在執行面：庫存太多、交貨不準時、品質不穩定...，這些都是非常作業面的東西，除非是對於該公司、該行業有一些了解，否則很難提出有效的解決方案。而一般外面的顧問公司大概都是拿些方法論去做，而遇到作業面的問題時，這些方法論不是很管用。反而需要實戰經驗才能有效的看出成果。

我遇過一個顧問公司的人，其實就是一個有經驗的老闆帶幾個年輕的顧問在幫公司做改善。他就是一個非常經驗豐富的人，知道現場管理的訣竅，所以可以透過一些動作改善生產效率。問他有什麼方法？其實他是說不出來的。

2) 問題的盤根錯節

前面也談到供應鏈的範疇之廣，所以一個問題通常只是冰山的一角，後面一堆相關事情都要一起弄，才有機會解決。例如：交貨不準時，這可能由研發的設計、銷售管理、採購、生產...所有大大小小的問題所造成的，並非生產管理部門的職責而已。對於一個顧問公司而言，這幾乎是要幫客戶看整個公司，甚至客戶、供應商的運作，才有辦法提出真正的解法。

在這樣的情形下，試想一個企業主，尤其是中小企業主，怎麼會願意花錢找顧問來幫忙？